Введение в KMS и envelope encryption

В этом посте рассмотрим, что такое вложенное шифрование и как оно применяется в KMS для защиты государственных и корпоративных секретов.

Введение

В последние 10 лет мы стали свидетелями множества несанкционированных утечек государственных и корпоративных данных. Начиная, от регулярных утечек данных из Facebook, которые начались со скандала с Cambridge Analytica, до недавних скандалов, которые затронули более 500M пользователей и обошлись Facebook в $276M штрафа.

Для Facebook потеря $276M не выглядит большой проблемой, но сам факт, что один из лидеров мирового IT рынка, на который работает более 50 тыс программистов, не может защитить СВОИ конфиденциальные данные, говорит о масштабе, сложности и срочности данной задачи.

Вторым примером является утечка emails и их содержимого Демократической Партии США. По данным расследования, в открытый доступ могли попасть избирательные планы, бюджетные ассигнования, оборонные бюджеты и контракты Пентагона. Расследование показало, что причиной утечки была неверная настройка AWS S3 bucket, в результате которой все бэкапы хранились в публичном bucket.

В России громкими примерами недавних утечек были сообщения(хотя и опровергнутые) об утечках в подрядчиках Альфа Банка и подтвержденные и признанные утечки СпортМастере, в Yandex.Еда. Финалом этой эпопеи стала атака на СДЭК 26 мая 2024г, в результате которой вирус смог повредить данные о клиентах и заказах путем несанкционированного шифрования и нанести репутационные и многомиллиардные убытки самому СДЭК.

После этой атаки политик и депутат Государственной Думы Александр Хинштейн в своем Телеграмм Канале дал свою оценку действиям Российского бизнеса в условиях СВО.

Прямые финансовые убытки Российских бизнесов оказались не большими, по сравнению со штрафами Facebook, но репутационные потери у утрату довения миллионов клиентов сложно недооценить.

Утечка данных кредитных карт клиентов большого банка - это практически гарантированное банкротство банка ПЛЮС дыра в бюджете государства после выплат по системе страхования вкладов.

Постановка задачи

Предположим, что у нас есть старый сервер с базой данных MySQL и мы хотим сделать такие вещи:

• Мигрировать базу данных на NWS без потерь данных и downtime
• Обеспечить автоматический snapshot и backup
• Ограничить доступ к базе для минимального количества юзеров и приложений при помощи IAM
• Обеспечить шифрованный доступ через TLS
• Защитить данные при помощи сервиса шифрования KMS

Шиврование в KMS

Перед началом рекомендую бегло ознакомится с базовыми терминами и документацией на KMS.

Для реализации envelope encryption для нашей БД, нам понадобится два ключа: DEK и KEK. На самом деле, ключей будет три, т.к MEK генерируется автоматически при создании пользователя.

Быстрый пример работы с dek можно посмотреть в cookbook.

Итак, начнем с обзора политик, которые разрешают использование KMS.

Напомню, что по умолчанию, ВСЕ сервисы блокируют неавторизованные вызовы и для их работы необходимо добавить IAM политику. Подробнее в документации и примере в cookbook.

Устанавливаем токен, следуя инструкции

Добавляем IAM политику, которая позволяет управлять ключами и шифровать/дешифровать данные:

tee kms.json <<EOF
{
  "id": "j689bw",
  "version": "0.0.1",
  "description": "allow key access, encryption and decryption for KMS service",
  "active": true,
  "statements": [
    {
      "sid": "sjmb2u",
      "effect": "allow",
      "actions": [
        "kms:list",
        "kms:create",
        "kms:delete",
        "kms:encryptblob",
        "kms:decryptblob"
      ],
      "resources": ["nrn:nws:friends:ru-msk-0a:*:*"],
      "principals": ["*"]
    }
  ]
}
EOF

Применяем данную политику:

nws iam policy create --config ./kms.json

Просмотрим все доступные ключи:

nws kms key-list --key-type all

Создаем два ключа: data encryption key и key encryption key:

nws kms key-add --key-type dek --alias demo/dek --desc "dek key for demo"

23 Apr 2024 13:11:22 MSK        INFO    ✅ Success! KMS key created:
        id: 1b193318-18d9-4eb8-a651-c82b803e91d6
        key type: dek
        alias: demo/dek
        description: dek key for demo

nws kms key-add --key-type kek --alias demo/kek --desc "kek key for demo"

23 Apr 2024 13:11:33 MSK        INFO    ✅ Success! KMS key created:
        id: ebadf53d-a369-400c-8532-6d55de9cbc76
        key type: kek
        alias: demo/kek
        description: kek key for demo

Сохраняем key-id и экспортируем в консоль:

export DEK_KEY_ID=1b193318-18d9-4eb8-a651-c82b803e91d6
export KEK_KEY_ID=ebadf53d-a369-400c-8532-6d55de9cbc76

Создаем демо файл, который будем шифровать:

tee hello.txt <<EOF
Hello World!
EOF

Шуфруем hello.txt при помощи DEK:

nws kms encrypt-blob --key-type dek --key-id $DEK_KEY_ID --input hello.txt --output hello.txt.dek

Шифруем DEK при помощи KEK:

nws kms encrypt-key --target-key-type dek --target-key-id $DEK_KEY_ID --encryption-key-type kek --encryption-key-id $KEK_KEY_ID

Получаем такое:

2024/04/23 12:26:19.674 INFO    rpc error: code = PermissionDenied desc = ❌ auth: forbidden

Что же случилось? Мы не добавили encrypt-key и decrypt-key методы в нашу IAM Policy!

Разрешение шифрования ключей

tee key-encryption.json <<EOF
{
  "id": "kx8zd3",
  "version": "0.0.1",
  "description": "allow key encryption",
  "active": true,
  "statements": [
    {
      "sid": "asxsnc",
      "effect": "allow",
      "actions": [
        "kms:encryptkey",
        "kms:decryptkey"
      ],
      "resources": ["nrn:nws:friends:ru-msk-0a:*:*"],
      "principals": ["*"]
    }
  ]
}
EOF

Добавляем политику:

nws iam policy create --config ./key-encryption.json

Снова пробуем шифровать DEK при помощи KEK:

nws kms encrypt-key --target-key-type dek --target-key-id $DEK_KEY_ID --encryption-key-type kek --encryption-key-id $KEK_KEY_ID

На этот раз получилось! Видим такое:

23 Apr 2024 20:10:28 MSK        INFO    ✅ Success! Key id 78703bf9-ed15-4bb7-a61b-127f5f883e06 encrypted with key id 88dfe8ad-663b-45c8-b205-544748a7e155

Пробуем дешивровать зашифрованный ранее файл уже после шифрования DEK:

nws kms decrypt-blob --key-type dek --key-id $DEK_KEY_ID --input hello.txt.dek.cipher --output hello.txt.dek

Смотрим разшифрованный файл:

cat hello.txt.dek

Видим, что содержимое нечитаемо и дешифрование небыло успешным и данные по-прежнему не доступны.

Дешифрование DEK и файла зашифрованных данных

nws kms decrypt-key --target-key-type dek --target-key-id $DEK_KEY_ID --encryption-key-type kek --encryption-key-id $KEK_KEY_ID

И снова дешифруем зашифрованный файл:

nws kms decrypt-blob --key-type dek --key-id $DEK_KEY_ID --input hello.txt.dek.cipher --output hello.txt.dek

Смотрим разшифрованный файл:

cat hello.txt.dek

На этот раз видим наши данные и подтверждаем, что дешифрование было успешным!

Эпилог

NWS KMS решает проблему хранения plaintext data во всех типах баз данных путем шифрования. KMS предлагает envelope encryption, которое позволяет шифровать ключи шифрования разными алгоритмами, повышая степень защиты данных.